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SMTP Service Extension for 8bit-MIMEtransport 


Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 

Official Protocol Standards" (STD 1) for the standardization state 

and status of this protocol. Distribution of this memo is unlimited. 
Abstract 


This memo defines an extension to the SMTP service whereby an SMTP 
content body consisting of text containing octets outside of the US- 
ASCII octet range (hex 00-7F) may be relayed using SMTP. 


1. Introduction 


Although SMTP is widely and robustly deployed, various extensions 
have been requested by parts of the Internet community. In 
particular, a significant portion of the Internet community wishes to 
exchange messages in which the content body consists of a MIME 
message [3] containing arbitrary octet-aligned material. This memo 
uses the mechanism described in [5] to define an extension to the 
SMTP service whereby such contents may be exchanged. Note that this 
extension does NOT eliminate the possibility of an SMTP server 
limiting line length; servers are free to implement this extension 
but nevertheless set a line length limit no lower than 1000 octets. 
Given that this restriction still applies, this extension does NOT 
provide a means for transferring unencoded binary via SMTP. 
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Framework for the 8bit MIME Transport Extension 
The 8bit MIME transport extension is laid out as follows: 


(1) the name of the SMTP service extension defined here is 
8bit-MIMEtransport; 


(2) the EHLO keyword value associated with the extension is 
8BITMIME; 


(3) no parameter is used with the 8BITMIME EHLO keyword; 


(4) one optional parameter using the keyword BODY is added to 
the MAIL FROM command. The value associated with this 
parameter is a keyword indicating whether a 7bit message 
(in strict compliance with [1]) or a MIME message (in 
strict compliance with [3]) with arbitrary octet content 
is being sent. The syntax of the value is as follows, 
using the ABNF notation of [2]: 


body-value ::= "7BIT" / "8BITMIME" 


(5) no additional SMTP verbs are defined by this extension; 
and, 


(6) the next section specifies how support for the extension 
affects the behavior of a server and client SMTP. 


The 8bit-MIMEtransport service extension 


When a client SMTP wishes to submit (using the MAIL command) a 
content body consisting of a MIME message containing arbitrary lines 
of octet-aligned material, it first issues the EHLO command to the 
server SMTP. If the server SMTP responds with code 250 to the EHLO 
command, and the response includes the EHLO keyword value 8BITMIME, 
then the server SMTP is indicating that it supports the extended MAIL 


command and will accept MIME messages containing arbitrary octet- 
aligned material. 


The extended MAIL command is issued by a client SMTP when it wishes 
to transmit a content body consisting of a MIME message containing 
arbitrary lines of octet-aligned material. The syntax for this 
command is identical to the MAIL command in [1], except that a BODY 
parameter must appear after the address. Only one BODY parameter may 
be used in a single MAIL command. 
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The complete syntax of this extended command is defined in [5]. The 
esmtp-keyword is BODY and the syntax for esmtp-value is given by the 
syntax for body-value shown above. 


The value associated with the BODY parameter indicates whether the 
content body which will be passed using the DATA command consists of 
a MIME message containing some arbitrary octet-aligned material 
("8BITMIME") or is encoded entirely in accordance with [1] ("7BIT"). 


A server which supports the 8-bit MIME transport service extension 
shall preserve all bits in each octet passed using the DATA command. 


Naturally, the usual SMTP data-stuffing algorithm applies so that a 
content which contains the five-character sequence of 


<CR> <LF> <DOT> <CR> <LF> 
or a content that begins with the three-character sequence of 
<DOT> <CR> <LF> 


does not prematurely terminate the transfer of the content. Further, 
it should be noted that the CR-LF pair immediately preceeding the 
final dot is considered part of the content. Finally, although the 
content body contains arbitrary lines of octet-aligned material, the 
length of each line (number of octets between two CR-LF pairs), is 
still subject to SMTP server line length restrictions (which may 
allow as few as 1000 octets on a single line). This restriction means 
that this extension MAY provide the necessary facilities for 
transferring a MIME object with the 8BIT content-transfer-encoding, 
it DOES NOT provide a means of transferring an object with the BINARY 
content-transfer-encoding. 


Once a server SMTP supporting the 8bit-MIMEtransport service 
extension accepts a content body containing octets with the high- 
order (8th) bit set, the server SMTP must deliver or relay the 
content in such a way as to preserve all bits in each octet. 


If a server SMTP does not support the 8-bit MIME transport extension 
(either by not responding with code 250 to the EHLO command, or by 
not including the EHLO keyword value 8BITMIME in its response), then 
the client SMTP must not, under any circumstances, attempt to 
transfer a content which contains characters outside the US-ASCII 
octet range (hex 00-7F). 


A client SMTP has two options in this case: first, it may implement a 


gateway transformation to convert the message into valid 7bit MIME, 
or second, or may treat this as a permanent error and handle it in 
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the usual manner for delivery failures. The specifics of the 
transformation from 8bit MIME to 7bit MIME are not described by this 
RFC; the conversion is nevertheless constrained in the following 
ways: 


(1) it must cause no loss of information; MIME transport 
encodings must be employed as needed to insure this is 
the case, and 


(2) the resulting message must be valid 7bit MIME. 
4. Usage Example 


The following dialogue illustrates the use of the 8bit-MIMEtransport 
service extension: 


<wait for connection on TCP port 25> 

<open connection to server> 

220 dbc.mtview.ca.us SMTP service ready 

EHLO ymir.claremont.edu 

250-dbc.mtview.ca.us says hello 

250 8BITMIME 

MAIL FROM:<ned@ymir.claremont.edu> BODY=8BITMIME 
250 <ned@ymir.claremont.edu>... Sender and 8BITMIME ok 
RCPT TO:<mrose@dbc.mtview.ca.us> 

250 <mrose@dbc.mtview.ca.us>... Recipient ok 
DATA 

354 Send 8BITMIME message, ending in CRLF.CRLF. 


NANANANNANAN 


250 OK 
QUIT 
250 Goodbye 


NANA 


5. Security Considerations 
This RFC does not discuss security issues and is not believed to 
raise any security issues not already endemic in electronic mail and 
present in fully conforming implementations of [1]. 
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